The ARM documentation describes linker feedback here:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474c/CHDFJGBE.html

Summed up by "Linker feedback is a collaboration between the compiler and
linker that can increase the amount of unused code that can be removed
from an ELF image".  In a nut-shell: it is information generated by the
link stage of a build that might usefully influence the compile stage in
subsequent builds.

Raptor supports ARM builds using linker feedback with RVCT via the
".linkerfeedback" variant and, from clean, it is a two stage process at its
simplest e.g. :

    sbs -c armv5.linkerfeedback
    sbs -c armv5.linkerfeedback

The first build sees a "normal" compile and link, with the exception that a
.fdb linker feedback file is generated into the build tree by the linker.

The second build is also a normal compile and link (re-compilation being
triggered by a dependency of the object files on any .fdb found to exist)
with the exceptions that:

i) the pre-existing .fdb file is referenced in compiler calls
ii) a "candidiate" .fdb file is generated by the linker and if (and only if)
    this differs from the pre-existing .fdb file then it is copied over the
    top to replace it

Any further ".linkerfeedback" builds operate as above i.e. if the linker
generates a candidate .fdb file different to that currently in use it is
copied to where it will trigger re-compilation in subsequent builds.

Note that, with builds from clean where no .fdb file exists, Raptor provides
info output into the log and at the terminal to indicate that a further build
is required to make use of the linker feedback file in later compilation:

    <info>Linker feedback file will be generated during the link of
          _ELF_FILE_ - re-build to use in compilation</info>
